Semo.js命令行工具项目复盘
项目简介
这是一个命令行开发工具类的项目，基于 yargs, 一般来说，如果你有一个想法，想写一个命令行工具，接收一些参数，根据参数做一些响应，这时你可以直接基于 yargs 或者 commander 库来写，难度也不大，问题是当你要写很多很多命令行工具，而且这些命令行工具是业务相关的，分布在公司内部不同的微服务里面，这时你不仅需要实现功能，还需要定一个规范，不然不同的命令行工具用不同的方法来实现，维护起来就是一场灾难，Semo.js 这个项目就是干这个用的。
项目背景
先说说起名字的事儿，众所周知起名字难死个人儿，我基本上是想一个要表达的含义，然后各种翻译成其他国家的语言，英语单词就不用想了，基本好的都被占了，终于皇天不负有心人，我找到了这个 Semo，这个词儿来自于世界语，大概是种子的意思，不管了，就它了。
在刚开始的时候，Semo的定义还是上面说的那样，解决 Node.js 微服务架构下，各个后端项目命令行工具规范的问题。但是后来，我萌生了写业务之外的命令行工具的想法，因此有一段时间我疯狂基于 Semo 开发一些玩具插件，同时修复这个过程中发现的 Semo 自身的一些不足。
这里就拿一个东东举例吧，就是咱们大掘进的命令行工具
npm i -g @semo/cli
semo run juejin -- pin -D
这样就可以在命令行刷掘进沸点了，在 iterm2 下还支持图片。
再后来，我觉得 Semo 本身应该还可以作为一个开发者友好的工具，这里我把时间重点花在开发一个相对好用的 REPL 环境上了。
各位大前端以及Node.js开发工程师可能平时很少用 node 自带的 REPL 工具吧，因为里面只能做一些基本的 Javascript 语法和 API 验证。我在这个地方有几点创新：
- 支持了 await 异步调用
- 支持了 注入第三方库
- 支持了 注入业务逻辑
后面两个其实是一回事，我能注入东西了，当然就可以注入业务逻辑进去，而业务逻辑又很多都是需要数据库连接和网络的，所以就要用 await 来触发，篇幅关系，这里就不展开说注入业务逻辑的事儿，对注入第三方库举个例子：
semo repl --require lodash:_
>>> _.add(1, 2)
3
在我的实际本地环境，我会注入很多常用的工具库，比如 day.js, lodash，randomatic 等等，众多工具库的 API 实在是背不下来，我都是现用现查，顺便谢谢测试代码。
一些心得
这个项目我从 17 年开始立项到现在已经维护了 3 年多的时间，这个项目至少对我个人来说是有用的，不知道大家觉得是不是有点用，在开发的过程中，我确实学到了很多东西，很多想法变为现实中间都要经过查资料，学习，写实验代码，优化等等步骤，很多命令行相关的知识点和相关的库都是在做这个项目的过程中接触到的。
这个项目属于工具型项目，对项目开发来说不是必须的，因此也就没有固定的使用场景，我个人也没有特别积极的推广，所以现在 star 数少的可怜，我感觉倒也不是特别在乎，不过，我真的觉得还是有点用的，推荐大家试试，我现在基本不打开 node 自带的 REPL 了，而 semo repl 是经常运行的，甚至是每天都开着。
我最近主要在给 Semo 写英文翻译，我的英文水平，那就是没有平，就是水，写的很痛苦，也很慢，大家看我的文档站就会发现了。不过也不要紧，我先翻译完，再慢慢优化了。Semo 的新特性我有好久没有添加了，不过我自己维护了一个长长的待办事项，他日得闲还是会慢慢添加新特性和优化的。
这个项目从设计上来说并没有什么好说的，我觉得设计的很一般，不像 React, Vue 这样的明星项目能造出一堆概念，我这里面有plugin, command, config, hook等几个概念，我觉得就挺好理解的，也够用，就是个命令行工具，不用搞得太复杂，相对于直来直去基于 yargs 开发命令行工具，这些概念也显得有点复杂了，但是换来的是灵活性和扩展性。
有一点比较遗憾，就是这个我目前来说投入精力最多的开源项目，并没有太多社区反馈，或者说没有形成社区，也就没有体验到 issue 驱动的开发体验，都是自己在给自己提需求，不过这个遗憾也许可以靠造别的更有价值的轮子来弥补吧，如果这个项目真的有人在用，也欢迎提 issue 哈。
最后在补充一点，如果大家对于开发插件感兴趣，可以去看我写的一个 hellworld 的插件的代码，可以远程运行这个插件看效果：
semo run hello-world